先講範圍

PII 在本系列只佔兩天（今天與 Day 16），原因寫在 Day 10 結尾：完整的去識別化、可控還原與台灣特種個資處理，是另一個 30 天系列《LLM 個資防護閘》的主題。今天只回答一個問題：Model Armor 的 SDP 整合能做到哪裡、做不到哪裡。

兩種模式

Model Armor 的 SDP 過濾器有兩種模式：

Basic 模式適合快速上線；Advanced 才是企業真正會用的，因為它能把命中的 PII 改寫後放行，而不是整段擋掉。

gcloud model-armor templates update ma-standard \
  --location=$MA_LOCATION \
  --advanced-config-inspect-template="projects/guardrails-lab-2026/locations/$MA_LOCATION/inspectTemplates/pii-tw" \
  --advanced-config-deidentify-template="projects/guardrails-lab-2026/locations/$MA_LOCATION/deidentifyTemplates/pii-tw-mask"

台灣 PII 的覆蓋：實測

DLP 內建的 infoType 對台灣證件的支援要實測，不能假設。用 Day 6 語料裡的 PII 子集（合成資料，非真實個資）跑：

內建沒有的，用自訂 infoType 補（regex ＋ 必要時 hotword 提升信心）：

{
  "infoType": {"name": "TW_NATIONAL_ID"},
  "regex": {"pattern": "[A-Z][12]\\d{8}"},
  "likelihood": "LIKELY"
}

注意這個 regex 不含 checksum 驗證——DLP 的 regex 做不到。這是雲端線在 PII 上的第一個邊界：內建與自訂 infoType 都是模式比對，台灣身分證的 checksum 得在 L1 自己做（Day 16）。

邊界一：它是偵測器，不是還原器

Advanced 模式可以把「A123456789」改成「[TW_NATIONAL_ID]」或「A1234*****」，但這是單向的。如果業務流程需要模型處理完再把真實值放回去（例如法務助理要輸出含當事人姓名的正式文件），SDP 做不到——這是可控還原的問題，屬於另一個系列的範圍。

邊界二：語境判斷

「請幫我查 A123456789 的申請進度」跟「身分證字號格式是一個英文字母加九個數字，例如 A123456789」——前者是真實查詢，後者是說明範例。SDP 兩個都會命中。要分辨語境需要 L2／L3，而且對合成範例的誤判在教育類場景會很高。

邊界三：特種個資

病歷、基因、性生活、健康檢查、犯罪前科（台灣個資法第 6 條）大多不是可用 regex 抓的型別，是語意層級的東西。DLP 有部分醫療相關 infoType，但對中文語境的支援要單獨測。本系列不深入，另一個系列會用專門的模型層處理。

邊界四：輸入與輸出要分開設

輸入端遮罩 PII 會讓模型看不到真實值，某些任務會因此做不了（例如「這個統編對應哪家公司」）。輸出端遮罩則是防止模型把它從 RAG 裡讀到的別人資料吐出來。兩端的政策應該不同：本系列的 ma-standard 輸入端只偵測不遮罩（記錄進稽核）、輸出端偵測並遮罩。

今天的結論

在合成 PII 語料（N 筆、六種型別）上，DLP 內建 infoType 覆蓋 ＿／6 種，加自訂型別後偵測率為 ＿%。checksum 驗證、可控還原、特種個資語意判斷三項為雲端線 SDP 的邊界，分別由地端 L1（Day 16）與《LLM 個資防護閘》系列處理。

明天預告

Day 12：惡意 URL 偵測與 streaming sanitization。輸出端最後兩個過濾器，以及 Day 3 留下的問題——串流模式下 Model Armor 用的是哪一種策略。

追蹤 AId3fend

Instagram @aid3fend。
更多 AI 資安筆記：aid3fend.com